Due to the limitation of physical conditions, when compared with wired links, wireless links in a mobile communication system have a lower transmission rate and a higher bit error rate. In order to make effective use of the limited wireless channel bandwidth resources, the Robust Header Compress (ROHC) technology is introduced. The core of ROHC is to use the information redundancy between packets of service flow to transparently compress and decompress information in packet headers between directly connected nodes. The ROHC technology is described by the RHC3095 document of Internet Engineering Task Force (IETF). But compression and decompression of an Internet Protocol (IP) header is not defined in the document, thus, in June, 2004, the ROHC working group has to separately define a framework for compression and decompression of the IP header in RFC 3843, and in February, 2007, the IETF revised the related documents of the ROHC, and the revised document is RHC 4815.
An Internet Protocol Identifier (IPID) is a field in an IP version 4 (IPV4), and each IP packet will carry the IPID, which is mainly used for fragmentation and recombination for IP packets. The position of a specific IP Identifier field in the IPV4 header is as shown in FIG. 1. In the network transmission process of an IP packet, if the size of the IP packet exceeds a Maximum Transmission Unit (MTU) of links at the bottom layer, the IP packet must be fragmented when it is allowed to fragment the IP packet, and when fragmentation data come to the next network node, it is determined whether these fragmentations belong to the same IP packet through the IPID of the IP header and the fragmentations are assembled to restore the original IP data.
The IPID is allocated by a generator of the IP packet according to certain strategies; the strategies which may be used will adopt allocation ways such as random allocation, sequential increment, and static constant and so on. If the generator of the IP packet adopts the random distribution way, the IPIDs of these IP packets follow no rules and they are rambling; if the generator of the IP packet adopts the allocation way of sequential increment, an IPID value in an IP packet generated latter will be increased compared with the former IP packer; if the generator of the IP packet adopts the allocation way of static constant, IPID field values in all IP packets generated by the generator are the same. The ways of random allocation and sequential increment are more common, while the allocation way of static constant is generally used in a Network Address Translation (NAT) environment, or when it is known that a Don't Fragment (DE) field in the IP header is 1 in a User Datagram Protocol (UDP) or a UDP-Lite, the IPID is set as a constant.
Because of such characteristics of IPID, the IPID can be compressed and decompressed by using certain algorithms in the ROHC, avoiding the transmission of an original value of the IPID in the wireless links as far as possible. For the ROHC, different allocations ways of the IPID correspond to different behaviors of the IPID, the random allocation way corresponds to random behaviors of the IPID, the sequential increment way corresponds to sequential behaviors of the IPID, and the static constant way corresponds to static behaviors of the IPID. When the behavior of the IPID is random, an original value of the IPID has to be carried in each package; when the behavior of the IPID is sequential, an IPID Offset coding scheme can be used to encode the IPID, and then the coded value is sent to an opposite end; when the behavior of the IPID is static, the original value only needs to be sent once at the beginning, and the related information of the IPID is not required to be sent in the package subsequently.
In the RFC 3095 protocol, an IPID Offset coding method is defined. With regard to IPIDs in an ascending order, a difference between the IPID and a Sequence Number (SN) is obtained, then the difference is coded through Window-based Least Significant Bits (WLSB) and then sent to the opposite end, after a decompressor of the opposite end receives the difference, the decompressor firstly performs Least Significant Bits (LSB) decompression to obtain the difference between the IPID and the SN, and eventually restores the original value of the IPID in combination with a restored value of the SN.
In the RFC 3843, a compression method for static IPIDs is defined, wherein, a compressor informs the decompressor of a situation that the IPID is static by adding related identifiers in initial refresh message, and sends the original IPID value to the decompressor, thus, the subsequent packages are not required to carry any information of the IPID, and the decompressor also can restore the original value of the IPID. When the IPID is allocated by the static constant way, the IPID Offset method cannot be used for encoding.
In the protocols of the ROHC, with respect to the behaviors of the IPID, the RFC 3095 gives an assumption that IPIDs in a wireless cellular network must be generally in an ascending order. With the increase of ROHC application scenarios and the progressive development of the protocols, this assumption is obviously out of date. Throughout the related protocols of the ROHC, only how to perform related compression and decompression according to the difference between the behaviors of the IPID is described, but no method for recognizing the behaviors of the IPID is provided. When the specific behaviors of the IPID are not known, it can be only believed that the behaviors of the IPID are random, so only the original IPID value can be sent each time, thereby wasting wireless resources and reducing the efficiency of compression and decompression.